Probably rather uncommon that people have custom networks. But this will break those setups right (until they explicitly change this value to Dockerfile.custom-network)

Correct. I had a choice of breaking it entirely or gating it behind this change. I asked Consensys whether they use the feature. They do not. It's a feature that Pandaops had asked for on behalf of client teams, and I am now unsure whether any client teams use it.

It'd be used for stuff like "devnet3"

On further thought. You likely can't even run a custom devnet with an image, it'd need to be source-built. Which means no one is using this feature

I've added a Dockerfile.source for this use case

Apparently this does not work with 'distroless' (according to Codex at least).

The web3signer script in the original image did

eval "set -- $(
          printf '%s\n' "$DEFAULT_JVM_OPTS $JAVA_OPTS $WEB3SIGNER_OPTS" |
          xargs -n1 |
          sed ' s~[^-[:alnum:]+,./:=@_]~\\&~g; ' |
          tr '\n' ' '
      )" '"$@"'

  exec "$JAVACMD" "$@"

But distroless does not.

Can set JAVA_TOOL_OPTIONS instead, but... only for distroless? Or also for regular image?

read_only is a Docker option. This absolutely works. So well in fact they had to fix Web3signer-distroless because it'd break when I turned that on: Consensys/web3signer#1175

AH ok, JAVA_OPTS. Yeah this likely doesn't work in distroless. We can point that out to Consensys as a bug

Let's leave that for another PR. JAVA_TOOL_OPTIONS is a good choice; we'd need to verify it doesn't interfere with what regular web3signer is doing